Hi, Item i = item(itemName) Permission p = delete|control set(i, p, "MFelger")
ManuelFelger - Tue Mar 10 08:14:15 EDT 2009 |
Re: Set access via dxl I don't recall if you must first turn of 'inheritence' before setting the access rights; but I would tend to do that and then erase whatever accesses there are, before setting the rights defined in your file. You are making a mistake turning off inheritence to every single thing in the database. For one thing, that will make each object its own 'section' will will make Shared mode practically worthless, and will drastically reduce module access time performance due to fragmentation of the physical database. For another, you'll need to mindfully adjust 1000s of accesses when you want to make access to anything; if you add group Testers to edit the module you will need to add that to most of everything in the module as well.
|
Re: Set access via dxl llandale - Tue Mar 10 18:01:46 EDT 2009
I didnt find the command to turn off inheritance for an item, can someone tell me? Manuel |
Re: Set access via dxl ManuelFelger - Wed Mar 11 06:55:27 EDT 2009 The command to turn off inheritance is "specific" look for this in DXL Help. |
Re: Set access via dxl ManuelFelger - Wed Mar 11 06:55:27 EDT 2009 ABC_Admins ... provides RMCDA access to everything in the project ABC_Writers ... provides RMCD access to everything in the project ABC_Readers ... provides R access to everything in the project We figure to provide those specific accesses to the Project folder, along with 'Everyone else' gets 'none', and inherit everything in the folder and we are done. Perhaps we should discriminate, providing a 'Creators' group with RMCD and the 'Writers' group with RMD. Project Managers manage the memberships of their groups. But we (as you do also) need more descretion. We may have more groups: ABC_Req_Writers ... can write to the Requirement Specs ABC_Test_Writers ... can write to the Test Specs. We had a proprietary folder containing stuff some folks must not see. We thus had these groups: ABC_MyPrivate_Readers ABC_MyPrivate_Writers Note sure you really WANT to make specific every single module; but as long as you use groups it will work, since group membership can be changes without modifying access rights (again) to the modules. The kingpin to this method is providing 'none' access to 'Everyone else' for everything in the Project with specific rights. The Group method of access rights provides accumulative access. If I have RD access via one group and RM via another, I get RMD access. Too bad there is no mechanism for using groups to restrict rights, such as using group 'KnownEnemySpies' to restrict access to something. You CAN provide each such person specific 'none' rights to something, but then you are not using groups and managing access effort blossoms out of control. I see commands 'inherited' and 'specific' to change the nature of access to something. IIRC, if you use 'specific' then the item will get by default whatever accesses it was previously inheriting, suggesting that you must first erase all access records before you apply the ones that you want. If you erase all access records then YOU will lack the power to provide anyone else access (since you lack 'RMCDA' access), unless you are the 'Administrator'. Alternatively, perhaps you can cleverly provide your own specific user name full RMCDA access, erase all OTHER access records, apply the ones from the file, then erase your specific record. I wonder what will happen if you provide a specific access record for a user or group when access is currently inherited. > Louie |
Re: Set access via dxl I really wouldn't do that if I were you. Setting specific access rights will cause a lot of admin overhead in future. Think carefully about why you need the control and at what level before you implement the changes. I would recommend creating 3 groups per project as Louie suggests. Project_Admins - RMCDA Project_Writers - RC, MD propogated Project_Readers - R And of course Everyone Else = None on entire database. The only difference from what Louie said is that I would set the Writers access to RC with MD propogated. This allows them all the access they need in the project, but prevents them from deleting or modifying the project itself. I think the mantra here is "Less is more..." |
Re: Set access via dxl Tony_Goodman - Wed Mar 11 12:05:12 EDT 2009 DOORS is a PUBLIC database. Maybe you don't want every user to see every module in a project but you DO want the majority of the users to see the majority of the modules. The whole purpose of using DOORS is to make links to other objects. If a user can't see a module, they also cannot link within that module. Manuel does not sound like he knows exactly what he is doing (don't be offended, Manuel--you may). Thus, I'm thinking that his requirement isn't an actual requirement; rather his management was told that they have to use DOORS instead of Word. After all, if Word documents are used instead of DOORS, then you can easily make it so that no one sees anything. If Manuel knows what his end goal is, great. It just doesn't sound to me like he's really thought this through, and we're giving him the technical answers about propagation and stuff without looking at the essence of his question. But after all of that, I will admit, I could be reading things wrong.... |
Re: Set access via dxl First, let suppose you have a Permission permission(string) and a Permission permission(AccessRec) function defined (I shown you before how to convert a permission from an Access Record into a string, just do it backward). Then, I think we can understand your request in two ways:
In the first case, you will only overwrite existing access record set on the same person or group. In both cases, you may need to detect a specific syntax for default access record ("Everybody Else" ?) In the second cases, you will need to keep track of already treated item: because you need to delete everything existing first, you shall not do it for each access on the same item. Moreover in the second case you need to temporary set RMCDA access to everyone: because you will remove all accesses including yours, you need everyone to control the item to keep admin access yourself. First case: (all-caps is pseudo-code or missing, to be written functions.) FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC specific item itemName // break inheritance if (IS DEFAULT ACCESS RECORD groupName) set (item itemName, permission accessRights, null) // Warning, default access is null string not empty ("") string else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //END OF FIRST CASE Second case: Skip listOfItems = createString() // key = itemName, value = default access FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC if (!find(listOfItems, itemName)) { // first line concerning this specific item string err put (listOfItems, itemName, permission (get (item itemName, null, err))) // store current, default access record specific item itemName // break inheritance set (item itemName, control, null) // set default access record to RMCDA before unsetting accesses unsetAll item itemName // remove every access record but the default one } //end if first line concerning this specific item if (IS DEFAULT ACCESS RECORD groupName) { // don't set default access record here, just store it for further use delete (listOfItems, itemName) // remove previously stored put (listOfItems, itemName, permission accessRights) // store new default access record } //end if is default access record else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //Now, restore stored default accesses Permission p for p in listOfItems do set (item (string key listOfItems), p, null) // key for listOfItems is name of item, value is default permission //END OF SECOND CASE |
Re: Set access via dxl ePiallat - Thu Mar 12 04:43:17 EDT 2009
In the first case, you will only overwrite existing access record set on the same person or group. In both cases, you may need to detect a specific syntax for default access record ("Everybody Else" ?) In the second cases, you will need to keep track of already treated item: because you need to delete everything existing first, you shall not do it for each access on the same item. Moreover in the second case you need to temporary set RMCDA access to everyone: because you will remove all accesses including yours, you need everyone to control the item to keep admin access yourself. First case: (all-caps is pseudo-code or missing, to be written functions.) FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC specific item itemName // break inheritance if (IS DEFAULT ACCESS RECORD groupName) set (item itemName, permission accessRights, null) // Warning, default access is null string not empty ("") string else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //END OF FIRST CASE Second case: Skip listOfItems = createString() // key = itemName, value = default access FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC if (!find(listOfItems, itemName)) { // first line concerning this specific item string err put (listOfItems, itemName, permission (get (item itemName, null, err))) // store current, default access record specific item itemName // break inheritance set (item itemName, control, null) // set default access record to RMCDA before unsetting accesses unsetAll item itemName // remove every access record but the default one } //end if first line concerning this specific item if (IS DEFAULT ACCESS RECORD groupName) { // don't set default access record here, just store it for further use delete (listOfItems, itemName) // remove previously stored put (listOfItems, itemName, permission accessRights) // store new default access record } //end if is default access record else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //Now, restore stored default accesses Permission p for p in listOfItems do set (item (string key listOfItems), p, null) // key for listOfItems is name of item, value is default permission //END OF SECOND CASE ABC_r R ABC_m RMCD ABC_Admin RMCDA Thats completely enough to specify access rights as long as the users are internal staff members, but the problem is, and thats why i thought about assigning specific access to single items, there are (and will be even more in future) external users who work on some projects. If they have to modify a module on a lower folder level in project ABC i would have to add them to group ABC_m and they could see and modify all files in the project, thats what i want to prevent. Do you have any other suggestions to solve this, i'm no longer convinced of the single access solution.. |
Re: Set access via dxl ManuelFelger - Thu Mar 12 08:32:46 EDT 2009 If you want them not to be able to see the bulk of the project but yet still want them to edit certain modules deep in the project (in this case w/o seeing the parent folders), you have a problem. IIRC in the past you could indeed open a module with DXL which provided R access even when the parent folder provided none, but I see just now (in DOORS v8.1) that you cannot do that anymore. You could provide R access to the folders and 'none' access to the modules therein, but that means all your items have specific access which is a major pain. Never dealt with propagated rights, but perhaps you could propagate 'none' access when the parent has 'R' access, and set all your folders to 'R' access and let your modules inherit, but that will prevent other folks from reading the modules. Not sure what to tell you other than move the modules to a folder made special for them.
|
Re: Set access via dxl Tony_Goodman - Wed Mar 11 12:05:12 EDT 2009 AAI Services, Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
Re: Set access via dxl ManuelFelger - Thu Mar 12 08:32:46 EDT 2009 You may have (almost) answered your own question, when you said "...there are (and will be even more in future) external users who work on some projects." Why not simply create a 4th group of users named "External", and for the specific modules that they require access to, in the Properties for that module, just uncheck the "Inherited" access box and "add" the External users group to have the needed access to that specific module. If possible and necessary, you could put several such modules in a single folder, and grant the access at the folder level to all the modules in it. Chris AnnalSW Test Engineer / DOORS Database AdministratorSensis Corporation, East Syracuse, New Yorkchrisa@sensis.com |
Re: Set access via dxl ePiallat - Thu Mar 12 04:43:17 EDT 2009
In the first case, you will only overwrite existing access record set on the same person or group. In both cases, you may need to detect a specific syntax for default access record ("Everybody Else" ?) In the second cases, you will need to keep track of already treated item: because you need to delete everything existing first, you shall not do it for each access on the same item. Moreover in the second case you need to temporary set RMCDA access to everyone: because you will remove all accesses including yours, you need everyone to control the item to keep admin access yourself. First case: (all-caps is pseudo-code or missing, to be written functions.) FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC specific item itemName // break inheritance if (IS DEFAULT ACCESS RECORD groupName) set (item itemName, permission accessRights, null) // Warning, default access is null string not empty ("") string else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //END OF FIRST CASE Second case: Skip listOfItems = createString() // key = itemName, value = default access FOR ALL CSV LINE, SET groupName, itemName, accessRights AS string AND DO CHECK itemName AS VALID NAME FOR ITEM CHECK groupName AS VALID NAME FOR USER, GROUP OR DEFAULT ACCESSREC if (!find(listOfItems, itemName)) { // first line concerning this specific item string err put (listOfItems, itemName, permission (get (item itemName, null, err))) // store current, default access record specific item itemName // break inheritance set (item itemName, control, null) // set default access record to RMCDA before unsetting accesses unsetAll item itemName // remove every access record but the default one } //end if first line concerning this specific item if (IS DEFAULT ACCESS RECORD groupName) { // don't set default access record here, just store it for further use delete (listOfItems, itemName) // remove previously stored put (listOfItems, itemName, permission accessRights) // store new default access record } //end if is default access record else set (item itemName, permission accessRights, groupName) // same syntax for both user and group NEXT CSV LINE //Now, restore stored default accesses Permission p for p in listOfItems do set (item (string key listOfItems), p, null) // key for listOfItems is name of item, value is default permission //END OF SECOND CASE How to uncheck the "Inherit from Parent" option via dxl script. Kindly do the needfull. If this is not possible, kindly reply back. Thank you! Regards, Shruthi |
Re: Set access via dxl Bosch - Thu Jun 16 04:05:54 EDT 2011 as pointed out by Pekka_Makinen in the thread you replied to, this would be the command "specific", as in code Object o for o in entire current Module do if (<my condition>) then specific o [/code] best regards, Mike |
Re: Set access via dxl SystemAdmin - Thu Jun 16 05:28:47 EDT 2011 Regards, Shruthi |